feat(opp-solana): drive resumable inbound dispatch; delete the depot-side terminal budget - #552

The memo is set before the chunks are staged, and a partially-staged buffer cannot be cranked — the comment asserts the opposite.

The comment reads "Memoize BEFORE the sends: even a partially-staged delivery leaves this relay able to crank once consensus tips via other operators." The program refuses exactly that case: read_staged_envelope (wire-solana instructions/opp/mod.rs:381-384) requires parsed.received_chunks == parsed.total_chunks, else TerminalChunkBeforeDataComplete; a buffer that was never created fails the owner check one step earlier.

So when the chunk loop throws partway (RPC hiccup, deadline, validator hiccup), _delivered_envelope is already set and the delivery propagates out to outpost_opp_job::run_outbound's catch with _last_outbound_epoch unset. Every read_inbound_envelope tick until the next successful outbound then takes the drain-then-read path at :1130, builds the manifest, and — once consensus tips via other operators — sends dispatch_attestations against our own incomplete buffer. skip_preflight is false (libfc solana_client.cpp:1726), so it is rejected at simulation rather than landing: no fee, but a guaranteed-to-fail RPC round trip plus a wlog on every inbound tick in that window.

Bounded — the next run_outbound tick re-uploads from offset zero and repairs it — but the window is real and the comment points the next reader the wrong way.

Suggest moving the assignment below the chunk loop (before or after the terminal epoch_in). The goal the comment actually wants — crank when our terminal call or drain failed but the buffer is complete — is served either way, and the partial case it claims to cover is not reachable by design.

The cost claim here is wrong: the drain builds the full effect manifest before it ever checks consensus or the cursor.

"Consensus-not-reached is a cheap internal no-op (one progress read) inside the drive loop" is true of drive_dispatch_rounds — but drain_dispatch does all of its manifest work first. extract_inbound_effects walks the envelope, then accounts_for_effect runs per effect, and every reserve-backed shape reaches reserve_info_for_codes, which costs two get_account_info calls (the Reserve PDA, then config_pda; the per-(token, reserve) cache does not span calls, and the config read sits inside the cached function rather than beside it).

For every operator except the one whose delivery tips consensus, that entire manifest is built and discarded — on every inbound tick, for as long as the epoch's outbound envelope is missing, which is precisely the window this call is designed to run in.

Scoped honestly: a steady-state envelope carrying only OPERATORS / BATCH_OPERATOR_GROUPS produces no reserve-backed effects and costs nothing extra. This bites on swap and reserve epochs — the busy ones, where the same envelope also has the most effects to walk.

Reading progress once at the top of drain_dispatch and returning early on !consensus_reached || dispatched_count >= total_attestations fixes both the cost and the comment, and subsumes the redundant pre-loop read flagged at :597.

The pre-loop cursor read and this guard are both dead — one get_account_info per drain with no behavioural contribution.

settled from :597 is consumed only by this line. Three lines down, :605 re-reads the same account and :612 overwrites settled before any other use, so the value from :597 never reaches the packing loop.

And this guard cannot fire for round ≥ 1 either: the bottom of the loop already returns on settled >= total_attestations (:680), so re-entry guarantees settled < total_attestations.

Initialising settled = 0 and dropping both lines is behaviour-identical. Walked against all twelve drive_dispatch_* expectations:

• already_drained_cursor_sends_nothing — falls through to :605, consensus is reached, :612 sets settled = 3, :631 returns without sending. Same outcome.
• consensus_not_reached_sends_nothing — reaches the :606 check one read earlier and returns. Same outcome.
• resumes_from_nonzero_cursor — unaffected; :612 is what seeds the resume, which is the fix for the original finding.

The only observable delta is that an already-drained epoch whose consensus flag is false now logs "consensus not yet reached" instead of returning silently, which is if anything the more accurate line. Worth doing because this drain now runs on every inbound tick, so the saved read is per-operator per-tick rather than once per envelope.

This hands drain_dispatch the original deadline duration rather than the remaining budget — the read path gets it right, this one does not.

read_inbound_envelope computes deadline_abs - fc::time_point::now() (:1132-1133); here the full deadline is passed after the chunk uploads have already consumed part of it, so drain_dispatch installs a fresh budget at :862.

Wall-clock is still capped, so this is not an overrun: fc::task::deadline_scope keeps the earliest of the previous and new deadlines (libfc fc/task/deadline.hpp:31-36), and http_client consults fc::task::current_deadline() (http_client.cpp:147), so RPCs still throw on the caller's real deadline.

The cost is diagnostic. The loop's own throw_if_past_deadline(deadline_abs, OP_DISPATCH_ATTESTATIONS) at :1021 can never fire first, so the OP_DISPATCH_ATTESTATIONS label — added by this PR specifically to identify this phase — is unreachable, and an operator whose drain runs long sees a generic transport timeout instead. Matching the read path's deadline_abs - fc::time_point::now() restores it.

Please drop this file from the PR.

It is session scaffolding rather than repository documentation — a checkbox task list addressed "For agentic workers", pinning an absolute local path (/home/valthon/wire-platform/wire-sysio), a build directory, and a commit-by-commit workflow that is already history. Its constraints are also written against a 114bfbd486 baseline that this branch has since been rebased off, so anyone who finds it under docs/ will be reading instructions that no longer describe the tree.

docs/opp-two-phase-dispatch-design.md is the genuine design doc and should stay — it is what makes this change reviewable. If this plan goes, docs/superpowers/specs/2026-08-11-contained-resumable-dispatch-relay-design.md is worth a second look too, since it exists to redirect this plan's placement.